Formatting: introduce esc_attr_name() for HTML attribute name sanitization - #12915

Nice addition — esc_attr_name() fills a real gap since esc_attr() only ever escaped values, not names, and the allowlist regex correctly strips all the characters that would let an attacker break out of the attribute-name context (quotes, =, <, >, /, whitespace, control chars). I checked out the branch, ran the new test file (33/33 pass) plus composer lint:errors and composer phpstan — both clean on the changed files (the pre-existing lint failures are in unrelated files).

One functional issue: src/wp-includes/formatting.php:20 (preg_replace( '/[^a-zA-Z0-9_.:\[\]-]+/u', '', $safe_text )) can return null instead of a string. wp_check_invalid_utf8( $text ) is called with the default $strip = false, so on a site whose blog_charset isn't UTF-8, is_utf8_charset() short-circuits it to return $text unmodified even if it contains invalid UTF-8 bytes. Those bytes then hit preg_replace() with the /u modifier, which returns null on invalid UTF-8 rather than throwing — I verified this directly (preg_replace('/[^a-zA-Z0-9_.:\[\]-]+/u', '', "caf\xE9") → NULL). That breaks the documented @return string contract. esc_attr()/esc_html() don't have this problem because _wp_specialchars() matches with a non-/u (byte-safe) pattern instead. Worth either passing wp_check_invalid_utf8( $text, true ) to always strip invalid bytes up front, or coalescing a null result from preg_replace() to ''. The test suite doesn't catch this because PHPUnit runs with the UTF-8 default charset.

Also, @since 7.1.0 on both the function and the esc_attr_name filter doc is likely wrong — trunk is currently 7.1-RC2 (feature-frozen), and other new hooks/functions already in trunk are tagged @since 7.2.0 (e.g. comment.php's recent additions), so this should probably target 7.2.0 too.